[Chapter 33] 33.5 The User Database
Author: Bryan Costales & Eric Allman
Date: 1999-01-06T20:25:27Z

#

| Chapter 33 Database Macros |

## 33.5 The User Database

The User Database is a special database file that you create for use by sendmail. It causes sender and recipient addresses to be rewritten under control of an external database file. Ordinarily, any local address is first looked up in the aliases database. If it is not found there, that user's ~/.forward is next examined. If the User Database is enabled, the address is looked up in that database after aliasing and before forwarding.

Lookup can be local via a database file, remote via a User Database server, or via a Hesiod network service. Here, we describe the database file form. The others are described in Section 34.8.75, UserDatabaseSpec (U).

### 33.5.1 Enable the User Database

The User Database is automatically enabled when you compile sendmail if you include support for NEWDB or HESIOD (see Section 18.8.54, USERDB). To see whether a precompiled version of sendmail includes User Database support, run it with the `-d0.1` switch:

>     % /usr/lib/sendmail -d0.1 -bt < /dev/null
>     Version 8.8.4
>      Compiled with: LOG MIME8TO7 NETINET NETUNIX NEWDB SCANF USERDB XDEBUG

>                                                                   note

If USERDB is listed, User Database support is included.

Next you must declare the location of its database file with the `UserDatabaseSpec` (`U`) option (see Section 34.8.75):

>     OU/etc/userdb.db                            in your cf file (V8)
>     O UserDatabaseSpec=/etc/userdb.db           in your cf file (V8.7)
>     define(`confUSERDB_SPEC',/etc/userdb.db)    in your m4 file

Here, the location of the database file is set to be /etc/userdb.db. You can also enable a default location for the database file that will take effect should the `UserDatabaseSpec` (`U`) option be missing by defining that location with UDB_DEFAULT_SPEC in compiling (see Section 18.8.53, UDB-DEFAULT-SPEC).

### 33.5.2 Create the User Database

The User Database is a `btree` class (see Section 33.8.1) database file created from a source text file using the makemap program:

>     % makemap btree /etc/userdb.db < /etc/userdb

Here, /etc/userdb is the source-text file that is input, and /etc/userdb.db is the database we are creating (the one defined by the `U` option in the previous section). [5]

> [5] The `.db` is added automatically if it is missing. We include it here for clarity.

The source-text file is composed of key and value pairs, one pair per line:

>     key    value

>       whitespace

The `key` is a user's login name, a colon, and one of two possible keywords: `maildrop` or `mailname`. The keyword that is chosen determines the nature of the `value`. `maildrop` The `value` is the official delivery address for this user. If there are multiple official addresses, they should either be listed as a single compound value, with separating commas, as, for example:

>     root:maildrop         sysadmin@here.us.edu,bill@there.us.edu

or be listed on individual lines:

>     root:maildrop         sysadmin@here.us.edu
>     root:maildrop         bill@there.us.edu

This latter form requires you to use the `-d` command-line switch with the makemap(1) program (see Section 33.2.1.1) when creating the database but has the advantage of being a simpler source file to manage. `mailname` The `mailname` keyword causes a "reverse alias" transformation, wherein the login name in the key is changed into the address in the value for outgoing mail. For example:

>     bob:mailname          Bob.Roberts@Here.US.EDU

This causes mail sent by `bob` to go out addressed as though it is from `Bob.Roberts@Here.US.EDU`. [6] This transformation occurs in the header and envelope. But note that the sender-envelope is not rewritten by UDB unless the `F=i` flag (see Section 30.8.24, F=i) is present in the delivery agent that is selected for the sender. Also note that the recipient headers are not rewritten by UDB unless the `F=k` flag (see Section 30.8.26, F=j) delivery agent is selected for the recipient.

> [6] Using full names in outgoing mail is probably not a good idea. Unlike login names, full names are not guaranteed to be unique. If current users expect to be able to receive mail under full names, future users with the same full name may be out of luck. Always weigh convenience against maintainable uniqueness when designing your mail setup.

Naturally, the `maildrop` and `mailname` keywords should occur in pairs. Each outgoing address that is created with `mailname` should have a corresponding `maildrop` entry so that return mail can be delivered. In the above example a reasonable pair might look like this:

>     bob:mailname          Bob.Roberts@Here.US.EDU
>     Bob.Roberts:maildrop  bob

Here, outgoing mail from the user named `bob` will be addressed as though it is from `Bob.Roberts@Here.US.EDU`. Incoming mail (whether it is original or in reply to the outgoing) will be addressed as though it is to the name `Bob.Roberts`, which will be transformed into and delivered to the local user `bob`.

### 33.5.3 A :default Outgoing Hostname

The `mailname` keyword allows the host part of outgoing addresses to mask the real hostname of the originating machine. This property can, for example, be used to convert the hostname into a firewall name:

>     bob:mailname          bob@Firewall.US.EDU

Here, the canonical name of `bob`'s machine is `Here.US.EDU`. The `mailname` keyword causes outgoing mail from `bob` to appear as though it is from the firewall machine (`Firewall.US.EDU`) instead.

Ordinarily, this transformation is not automatic. Each username that is to appear to be from the firewall machine will need an entry like that above in the User Database. To automate this process, you can use the special username `:default` in a `mailname` declaration:

>     :default:mailname     Firewall.US.EDU

If a `maildrop` entry is found for a particular name, but no corresponding `mailname` record is found, the outgoing address is ordinarily unchanged. If, however, a default hostname has been defined with `:default`, that hostname replaces the local hostname for all addresses that lack their own `mailname` entry:

>     :default:mailname     Firewall.US.EDU
>     bob:maildrop          bob@here.us.edu

In this example the user `bob` has a `maildrop` entry but lacks a `mailname` entry. Outgoing mail from this user will have the `:default` hostname used instead of the local hostname. The user `sally`, on the other hand, has neither a `maildrop` entry nor a `mailname` entry and so will not have her outgoing address rewritten.

33.4 Use Maps with $( and $) in Rules |  | 33.6 Database Maps and m4